%%
%% Chord Project with ProActive
%%  
%% Author : Laurent PELLEGRINO
%% Version : 09/11/2009

\documentclass[a4paper, 11pt]{article}

\usepackage[utf8]{inputenc}
% Adaptation au français
\usepackage[french]{babel}
% Pour de jolies entêtes
\usepackage{fancyhdr}
% Pour inclure des images
\usepackage{graphicx}
% Tableaux à largeur variable
\usepackage{tabularx}
% Pour certaines formules mathématiques
\usepackage{amsmath}
% Pour colorer les tableaux
\usepackage[table]{xcolor}
% Pour gérer les marges
\usepackage{geometry}
% Compteur de page
\usepackage{lastpage}
\usepackage[T1]{fontenc}
\usepackage{fancybox}
\usepackage{parskip}
\usepackage[colorlinks=true, urlcolor=blue, linkcolor=black]{hyperref}
% Répertoire des images
\graphicspath{{images/}}
\setlength{\parindent}{15pt}

\begin{document}

% Entete & Pied de page
\pagestyle{fancy}
\lhead{\textit{Master 2 IFI}}
\rhead{\textit{Peer-to-peer}}

% Page de garde
\begin{titlepage}
	\'Ecole Polytech'Nice-Sophia \hfill Master d'informatique 2\up{\`eme} année
	\vfill
	\begin{center}
		\begin{tabular}{c}
				\textbf{\Huge{Chord-ProActive}}
				\\ \\
				A simple Chord implementation using the ProActive middleware
		\end{tabular}
	\end{center}
	\vfill
	\begin{center}
		\begin{tabular}{ll}
			\multicolumn{2}{c}{\textbf{Etudiants}}\\
			Anthony & \bsc{Parisy}\\
			Laurent  & \bsc{Pellegrino}\\
			Marc  & \bsc{Valdener}\\
			\\
			\multicolumn{2}{c}{\textbf{Encadrant}}\\
			Luigi & \bsc{Liquori}\\
		\end{tabular}
	\end{center}

	\vfill
	\begin{flushright}
		2009-2010
	\end{flushright}
\end{titlepage}


\section{Introduction} % (fold)
\label{sec:introduction}
L'objectif du présent document est de donner les informations nécessaires pour une compréhension rapide du développement réalisé dans le cadre du projet Chord, mais également d'expliquer nos choix techniques.

Pour la réalisation du projet nous avons créé un projet google-code à l'adresse suivante afin de pouvoir au mieux se synchroniser à l'aide d'un gestionnaire de version tel que subversion :
	
\href{http://code.google.com/p/chord-proactive}{http://code.google.com/p/chord-proactive}


Toutes les ressources du projet sont disponibles en téléchargeant l'archive suivante :

	\href{http://chord-proactive.googlecode.com/files/chord-parisy-pellegrino-valdener.tar.bz2}{http://chord-proactive.googlecode.com/files/chord-parisy-pellegrino-valdener.tar.bz2}

% section introduction (end)

\section{Environnement} % (fold)
\label{sub:environnement}

Afin de mener à bien le projet, nous nous sommes appuyés sur le langage Java qui nous a permis un développement rapide mais également sur divers outils et librairies tels que :

\begin{itemize}
	\item[\textbf{Maven}] afin de gérer les différentes versions des librairies utilisées mais aussi pour facilement générer un bundle\footnote{Archive d'un projet contenant toutes les dépendances nécessaires et prête à être déployée}.
	\item[\textbf{ProActive}] qui est une librairie permettant la création d’objets distants, la mobilité des applications, les appels de méthodes asynchrones et les communications de groupe. Avec un ensemble réduit de primitives, ProActive fournit une API permettant la programmation d’applications distribuées pouvant facilement être déployées aussi bien sur des réseaux locaux (LAN) que sur un ensemble de grilles de calcul interconnectées via Internet. ProActive à également était choisi car ce projet Chord doit à terme être intégré dans une branche du projet ProActive dans le cadre de l'élaboration par Laurent d'une bibliothèque de réseaux pair-à-pair structurés.
	\item[\textbf{Jung}] Java Universal Network/Graph Framework  permet de simplifier la création et la manipulation de graph. Cette librairie a été utilisé pour réaliser l'interface graphique.
\end{itemize}

Le choix de ces outils pour un tel projet est certes discutable mais est nécessaire pour une réutilisation future à plus grande échelle et dans le contexte d'intégration au projet ProActive.
% section environnement (end)

\section{Présentation} % (fold)
\label{sec:présentation}

Une fois l'archive \textbf{chord-parisy-pellegrino-valdener.tar.bz2} téléchargée et décompressée, vous y trouverez le contenu suivant :

\begin{itemize}
	\item \textbf{report.pdf} la documentation que vous êtes en train de lire;
	\item \textbf{chord-proactive-javadoc.tar.bz2} contenant la javadoc du projet;
	\item \textbf{chord-proactive-src.tar.bz2} contenant les sources du projet;
	\item \textbf{chord-proactive-bundle.tar.bz2} contenant les binaires ainsi que les librairies et les scripts nécessaires au lancement et à la visualisation d'un réseau Chord.
\end{itemize}

Les sources sont décomposées en trois modules Maven :

\begin{itemize}
	\item \textbf{chord-proactive-core} le coeur de l'application implémentant le protocole Chord;
	\item \textbf{chord-proactive-samples} contient l'implémentation du client en mode console ainsi que les scripts de lancement des exemples;
	\item \textbf{chord-proactive-gui} contient l'implémentation du client graphique.
\end{itemize}

\paragraph{}Chacun de ces modules respecte l'arborescence imposée par Maven c'est à dire un dossier src/ décomposé en deux dossiers : test et java. Le premier contenant l'implémentation des tests, le second contenant les sources de l'implémentation. Chacun de ces deux dossiers pouvant également contenir un dossier nommé resources/ qui sera placé dans le classpath Java. Ce dossier sert à y placer diverses ressources tel que des icônes comme ce fût le cas pour l'interface graphique cliente ou bien des scripts.

Au cours du développement nous avons réalisé quelques tests unitaires et de non-régression pour le module \textbf{chord-proactive-core}. Ces derniers nous ont permis de s’assurer que des bogues n’ont pas été introduits dans des parties non modifiées de l'application lors de l'ajout de fonctionnalités.

Les principales classes sont :

\begin{itemize}
	\item[\textbf{ChordNode.java}] qui définit un pair Chord avec les différentes opérations associées telles que join, leave, put, get, etc. L'implémentation reste assez similaire au pseudo-code du délivrable officiel.
	\item[\textbf{Key.java}] qui définit un identifiant associé à un noeud ou bien aux ressources stockées sur les pairs. Cette classe prend en paramètre un identifiant sous forme d'un entier ou d'une chaine de caractère qui sera ensuite haché, réduit à l'intervalle $[0,2^{Key.NB\_BITS}[$ et stocké en tant que BigInteger afin de ne pas être limité sur le nombre de clés pouvant être gérées même si cela peut légèrement ralentir l'application comparé à un type primitif. Il est important de noter qu'on peut modifier la valeur de Key.NB\_BITS afin d'augmenter le nombre de pairs autorisés dans chaque réseau Chord. Par défaut cette valeur est fixée à 5. 
	\item [\textbf{FingerTable.java}] qui définit la finger table stockant les successeurs en puissance de 2. Le nombre d'entrées est égale à Key.NB\_BITS.
\end{itemize}

Pour de plus ample information, la documentation javadoc est un bon complément à ce compte-rendu pour comprendre l'implémentation.

\section{Choix techniques} % (fold)
\label{sec:choix_techniques}

Divers choix techniques ont été réalisés durant le projet. Certains ont été contraint par le choix du language tandis que d'autre ont été fait après s'être documenté.

\subsection{Tracker} % (fold)
\label{sub:tracker}
	
	Nous avons utilisé la notion de Tracker afin de pouvoir maintenir des références vers des pairs appartenant à un réseau pair-à-pair. Cela permet d'avoir à tout moment des points d'entrée dans le réseau. En théorie, non pas une référence vers tous les pairs, mais un ensemble suffisamment grand pour tolérer un certain nombre de pannes. 

Dans notre cas, chaque Tracker est associé à un réseau Chord et permet de maintenir une référence vers des pairs appartenant à ce réseau. Afin d'éviter de ne plus pouvoir visualiser le réseau en cas de crash des pairs mémorisés par le tracker, nous avons choisi de fixer la probabilité qu'un Tracker mémorise une référence vers un pair distant à $1$. Cette probabilité est fortement liée à la taille du réseau. De ce fait si on veut être \og scalable \fg il se doit de choisir une valeur cohérente. Dans la section {\bfseries Perspectives d'évolutions} nous évoquons également comment nous pourrions améliorer la tolérance aux pannes sur ce point de vue.
% subsection tracker (end)

\subsection{Communication par messages} % (fold)
\label{sub:communication_par_messages}

Communiquant par appels de méthodes, les objets récupérés après un appel distant étant des copies de l'objet original, il n'est pas utile d'altérer directement cet objet auquel cas seul la copie locale serait modifiée et non l'objet original. Pour cette raison, nous avons dû mettre en place un système de communication par message. Cela permet par exemple lorsque l'on souhaite ajouter une Entry (couple clef, valeur) à un noeud Chord,  d'encapsuler l'action dans un message qui sera réceptionné par le noeud souhaité et qui lors de la réception va traiter l'action qui dans notre cas consistera à ajouter le couple en question à ses entries. Après quoi une réponse est retournée à l'envoyeur.

Cette notion est implémentée dans le package fr.unice.polytech.chord.core.messages du module \textbf{chord-proactive-core}.

% subsection communication_par_messages (end)

\subsection{Tolérance aux pannes} % (fold)
\label{sub:tolérance_aux_pannes}

Nous avons implémenté la tolérance aux pannes. Lorsque des noeuds se déconnectent violemment (en cas de crash de la machine sur laquelle ils sont déployés par exemple) il est nécessaire, malgré le noeud faisant défaut, que les requêtes puissent toujours être effectuées. Un noeud défectueux peut soit apparaître en tant que successeur direct d'un noeud, soit figurer dans la finger table. Dans les deux situations, le comportement à adopter est assez simple et n'entraîne qu'une modification mineure des algorithmes existants. Il suffit d'envoyer la requête au plus proche des noeuds valides dans la finger table par rapport au noeud défectueux. Ensuite grâce à l'algorithme de stabilisation, les finger table et le noeud dont le successeur est défectueux corrigeront d'eux-mêmes les incohérences. Cependant il se peut que plusieurs noeuds successeurs soient défectueux auquel cas l'anneau Chord pourrait être scindé en deux et avoir des successeurs incohérents. Pour résoudre en particulier ce problème, nous avons utilisé une liste de $R$ successeurs pour chaque noeud. Cela permet de tolérer $R-1$ fautes.

% subsection tolérance_aux_pannes (end)

% section choix_techniques (end)

% section présentation (end)

\section{Déploiement de l'application} % (fold)
\label{sec:déploiement_de_l_application}

Pour déployer l'application, il faut commencer par décompresser l'archive \textbf{chord-proactive-bundle.tar.bz2} précédemment récupérée. Une fois ceci fait, vous devez vous déplacer dans le dossier chord-proactive-samples-1.0-SNAPSHOT/ dans lequel vous y trouverez trois scripts SH permettant de déployer l'application :

\begin{itemize}
	\item tracker-launcher.sh : permet de démarrer un tracker;
	\item chord-launcher.sh : permet de démarrer un client en mode console;
	\item chord-visualizer-launcher.sh : permet de démarrer un client en mode graphique.
\end{itemize}

Le déploiement de l'application se déroule en deux étapes : le déploiement d'un tracker et le lancement d'une ou plusieurs applications clientes en mode console ou graphique.

\subsection{Déploiement d'un Tracker} % (fold)
\label{sub:déploiement_d_un_tracker}

Le déploiement d'un Tracker est une étape indispensable pour la création d'un Overlay. Pour ce faire il suffit d'exécuter le script \og tracker-launcher.sh \fg{} en lui indiquant en paramètre un nom permettant de l'identifier. Cela permet de pouvoir lancer plusieurs trackers sur la même machine. Même si pour le moment chaque réseau Chord est limité à l'utilisation d'un seul tracker. En retour vous obtiendrez l'URI par laquelle le tracker est accessible.

\begin{verbatim}
	$ ./tracker-launcher.sh chord
\end{verbatim}

% subsection déploiement_d_un_tracker (end)

\subsection{Déploiement d'un client} % (fold)
\label{sub:déploiement_d_un_client}

Pour démarrer un client que ce soit en mode console ou graphique, il faut disposer de l'URI d'un Tracker actuellement déployé afin de récupérer un point d'entrée dans le réseau. Une fois cette adresse récupérée, il suffit d'exécuter un des deux scripts disponibles permettant de lancer un client en lui passant l'URI du Tracker en paramètre. Ci-dessous un exemple pour démarrer un client en mode console :
\begin{verbatim}
	$ ./chord-launcher.sh rmi://localhost:1099/chord
\end{verbatim}
% subsection déploiement_d_un_client (end)

Afin de tester les communications distantes il suffit déployer un client sur une autre machine en utilisant l'adresse sur la laquelle est binder le tracker de la première machine. Veillez à ce que les machines soient défiltrées et permettent l'utilisation du port en question qui est ici le port 1099. Il est bien entendu possible via les propriétés ProActive d'indiquer le port ainsi que le protocole à utiliser tel que rmi, http, etc. Cependant ceci dépasse le cadre de la documentation que nous voulions simple et concise. En cas de besoin vous pouvez nous contacter.
% section déploiement_de_l_application (end)

\section{Mode console} % (fold)
\label{sec:mode_console}

Le mode console permet d'interagir avec un réseau Chord afin d'obtenir diverses informations telles que les pairs se trouvant actuellement dans le réseau, ajouter des pairs, etc. Une fois le mode console démarré, on obtient une interface similaire à ce qui suit :

\begin{verbatim}
	Select an action to perform from vis157d.inria.fr:
	   (*) join <key> : Inserts a new chord node with the specified key on the overlay
	   (*) leave <key> : Asks to a node with a given key to leave the overlay
	   (*) get <key> : Retrieves a value associated to a key
	   (*) put <key> <value> : Put a key/value on the overlay
	   (*) remove <key> : Removes an entry on the overlay by using key
	   (*) list : List nodes on the current overlay
	   (*) quit : Quit the application

	> 
\end{verbatim}

On peut remarquer qu'on dispose de diverses commandes. Chaque commande indique entre chevrons les paramètres nécessaires. Cette application est robuste c'est-à-dire qu'elle supporte tout type d'entrées clavier et divers scénarios : que ce soit l'ajout d'un noeud avec une clé existante sur le réseau ou bien l'entrée de lettres à la place de chiffre pour indiquer une clé, etc. Dans tous les cas qu'une commande échoue ou pas, vous aurez la possibilité d'entrer de nouvelles commandes. 

\paragraph{} Le mode console gère l'historique des commandes tapées en appuyant sur les touches \ovalbox{$\uparrow$} et \ovalbox{$\downarrow$} du clavier, mais également la complétion automatique en appuyant sur \ovalbox{tab$\rightarrow$}.

\paragraph{} Voici un exemple d'ajout d'un noeud Chord :

\begin{verbatim}
	> join 7
	[INFO  ChordNode] Node 7 is created
	[INFO  ChordNode] Node 7 has created a new network!
	*** Node with key 7 has joined the network	
\end{verbatim}

En cas d'ajout d'un nouveau pair avec la même clé, l'opération sera abandonnée et vous en serez notifié :

\begin{verbatim}
	> join 7
	[INFO  ChordNode] Node 7 is created
	*** A node with key '7' already exist, operation is snubbed
\end{verbatim}

De même si vous tentez de saisir des paramètres incorrects :

\begin{verbatim}
	> join abc
	*** Key argument must be a number
\end{verbatim}

\paragraph{} Les descriptions des commandes sont dans l'ensemble assez explicites. Cependant il se doit de noter que la commande put permettant d'ajouter un couple $(clef, valeur)$ sur le réseau, accepte comme valeur une chaîne de caractère :

\begin{verbatim}
	> put 13 Une courte phrase
	[INFO  ChordNode] Nobody on the network contains the key
	[INFO  ChordNode] (13,Une longue phrase) has been added on node 7
	*** (13,Une longue phrase) has been added on the overlay
\end{verbatim} 

Il est également important de comprendre les informations retournées par la commande list (alias \verb+ll+). Ainsi après l'ajout du noeud 26 on obtient :

\begin{verbatim}
	> ll
	Overlay currently contains :
	  - Node 7 has P=26, S=26, FT=[26 26 26 26 26], S=[26,7,26], E=[]
	  - Node 26 has P=7, S=7, FT=[7 7 7 7 26], S=[7,26,7], E=[(13,Une courte phrase)]
\end{verbatim}

Pour chaque noeud, la commande indique le prédécesseur P, le successeur S, les entrées de la finger table. Ici on a 5 entrées dans la finger table car la taille de la clé est fixée à $2^5$ ce qui autorise 32 pairs par réseau Chord. On dispose également de la liste des successeurs S utilisée en cas de détection d'une failure lors d'un appel de méthode sur un successeur et de la liste des entrées $(clef, valeur)$ stockées sur le pair courant. Lorsqu'un point d'interrogation (?) apparaît dans la finger table ou la liste de successeur, cela signifie qu'un pair à quitté le réseau ou qu'un pair a crashé et que la stabilisation est en cours.

\paragraph{} Il est possible d'afficher plus d'informations concernant l'exécution à l'aide des logger utilisés. Il est notamment possible d'afficher les informations de déboguage pour voir la trace d'appel des différentes fonctions. Pour cela il suffit d'éditer le fichier resources/log4j.xml de l'archive bundle décompressée pour remplacer \verb+<level value="info" />+ par \verb+<level value="debug" />+.

\paragraph{} Pour information, les pairs ajoutés sont déployés sur la même machine que celle où est exécutée la commande d'ajout d'un pair. De ce fait, quitter le mode console implique donc de tuer brutalement les pairs ayant été déployé sur cette machine. Ceci est un choix d'implémentation. Nous aurions pu choisir de quitter proprement en faisant quitter un par un les pairs déployés mais cela aurait entraîné une attente de la part de l'utilisateur. De plus, la tolérance au pannes étant gérée cela ne pose aucun soucis.
% section mode_console (end)

\section{Mode graphique} % (fold)
\label{sec:mode_graphique}

L'interface graphique cliente présentée sur la Figure \ref{chord-visualizer} est décomposée en plusieurs parties qui vont vous êtes présentées ci-après.

\paragraph{Information} Nous avons utilisé le Look and Feel \og Nimbus \fg{} pour l'interface graphique. Cela implique de disposer d'un version de Java 6 supérieure ou égale à Java 6 update 10 sous Windows et Linux tandis que sous Mac OS X votre version de Java doit être supérieure ou égale à Java 6 update 17.

\begin{figure}[b]
	\begin{center}
		\includegraphics[width=0.95\textwidth]{chord-visualizer.png}
		\caption{Aperçu de l'interface graphique}
		\label{chord-visualizer}
	\end{center}
\end{figure}

\subsection{Barre des menus} % (fold)
\label{sub:barre_des_menus}

Cette barre de menu est plutôt classique. Elle regroupe uniquement les actions que nous ne souhaitions pas faire figurer dans l'interface elle même telles que \og Quit \fg, \og Help \fg{} et \og About \fg).
% subsection barre_des_menus (end)

\subsection{Barre d'outils} % (fold)
\label{sub:barre_d_outils}

La barre d'outils située dans la partie supérieure de l'interface graphique regroupe toutes les actions de l'application. C'est-à-dire toutes les interactions qu'on peut effectuer avec le réseau Chord qu'on visualise. Les différentes actions sont dans l'ordre d'apparition des boutons de la barre d'outils :

\begin{itemize}
	\item \textbf{Add Node} qui permet d'ajouter un noeud sur le réseau en indiquant l'identifiant de clef à associer au noeud.
	\item \textbf{Remove Node} qui permet de forcer un pair donnée à quitter proprement le réseau.
	\item \textbf{Add Entry} qui permet d'ajouter une Entry/Entrée c'est-à-dire un couple (clef,valeur) dans le réseau. Il important de noter qu'on peut soit indiquer la clef et la valeur associée à chaque entrée soit indiquer uniquement la valeur de l'entrée et laisser le champs clef vide. Auquel cas la clef sera automatiquement générée en hachant la valeur de l'entrée.
	\item \textbf{Remove Entry} qui permet de supprimer une entrée en indiquant sa clef.
	\item \textbf{Show Entries} qui permet de voir les entrées contenues sur le réseau et sur quels noeuds elles se trouvent. Une fois cette boîte de dialogue ouverte, il est possible de la laisser ouverte dans un coin de la fenêtre puisque elle est rafraîchit automatiquement toutes les 2 secondes.
	\item \textbf{Refresh} qui permet de rafraîchir le graph en cas d'incohérence graphique. Normalement il est inutile de l'utiliser car le graph est automatiquement rafraîchit toutes les secondes. Cependant il vaut mieux avoir la possibilité de le faire en cas de soucis. 
\end{itemize}
% subsection barre_d_outils (end)

\subsection{Canvas Jung} % (fold)
\label{sub:canvas_jung}

La canvas Jung est la partie centrale de l'interface graphique qui permet de visualiser le réseau Chord. Pour dessiner et maintenir le graph associé au réseau Chord, nous avons utilisé la librairie Jung comme déjà mentionné au début de cette documentation. Chaque noeud Chord est représenté par un cercle rouge auquel est associé un son identifiant. Les arc en noirs représentent les liens successeurs, prédécesseurs.

Grâce à cette librairie nous avons pu réaliser quelques fonctionnalités intéressantes notamment lorsque la représentation graphique contient plusieurs noeuds. Il est ainsi possible de déplacer le graph en tenant appuyé le bouton droit de la souris, de zoomer et dézoomer en scrollant avec la souris, mais également de faire pivoter le graph en tenant appuyé la touche \ovalbox{Shift $\uparrow$} et le clic gauche de la souris.

Il est également possible à tout moment de cliquer sur un noeud Chord représenté en rouge. Auquel cas celui-ci deviendra bleu et vous verrez apparaître des arcs bleu qui représentent les liens vers les finger de la finger table du noeud sélectionné. Vous devez noter que si par exemple un noeud contient deux fingers vers un même noeud Chord dans sa finger table, un seul arc sera dessiné.

% subsection canvas_jung (end)

\subsection{Canvas Informations} % (fold)
\label{sub:subsection_name}

La partie se trouvant à droite du canvas Jung permet d'effectuer une recherche par clef mais également d'afficher des informations sur le dernier pair sélectionné dans le graph.

\subsubsection{Lookup} % (fold)
\label{ssub:lookup}
Le champs lookup permet d'effectuer une recherche à partir d'un clef, que ce soit une clef associé à un noeud ou à une donnée. Dans tous les cas vous obtiendrez une réponse. Un cas particulièrement intéressant et lorsque vous entrez une clef qui correspond à la clef d'un noeud existant dans le réseau. Dans ce cas, une fenêtre de dialogue s'ouvre afin de visualiser toutes les entrées associées au noeud en question. Comme pour la boîte de dialogue \og Show Entries \fg précédente, vous pouvez la laisser ouverte afin de constater toute évolution étant donné que celle-ci est rafraîchit régulièrement.
% subsubsection lookup (end)

\subsubsection{Informations} % (fold)
\label{ssub:informations}
	La partie informations apparaît uniquement lorsqu'un noeud du graph est sélectionné, c'est-à-dire lorsque vous avez cliqué dessus. Auquel cas vous verrez apparaître pour ce noeud l'identifiant des noeuds prédécesseur et successeurs ainsi que sa finger table.
% subsubsection informations (end)

% subsection subsection_name (end)

\subsection{Barre de statut} % (fold)
\label{sub:barre_de_statut}

La barre de statut est un simple JLabel qui affiche en temps réel le nombre de pairs dans le réseau mais également la taille de la clef (en bits) ce qui permet d'en déduire le nombre de noeuds et d'entrées autorisées dans le réseau Chord.
% subsection barre_de_statut (end)

% section mode_graphique (end)

\section{Scénario d'utilisation} % (fold)
\label{sec:scénario_d_utilisation}

Nous allons décrire ci-dessous un scénario d'utilisation afin de mettre en évidence certaines fonctionnalités implémentées.

Supposons la configuration suivante :
\begin{itemize}
	\item Machine A : tracker déployé
	\item Machine B : client mode console lancé
	\item Machine C : client mode graphique lancé
\end{itemize}
\paragraph{} Pour commencer, créons deux noeuds depuis B et un depuis C ayant respectivement comme valeur de clef 2, 101, 344. La création du noeud 101 depuis la console va indiquer que le noeud 5 à rejoint le réseau. Cela peut paraître déroutant mais il faut toujours garder en tête qu'on travaille module $2^{Key.NB\_BITS}$ soit par défaut $2^5=32$. Le mode graphique quand à lui, lors de l'ajout de 344 indique que le noeud 24 à rejoint le réseau en précisant que $344 = 24$ mod $32$. Cette distinction a été faites en supposant qu'en mode console l'utilisateur sait ce qu'il fait et connaît comment fonctionne Chord. 

Ayant trois noeuds, il peut être intéressant d'ajouter une Entry depuis C d'ajouter par exemple une clef 12 et une valeur choisie aléatoirement. On remarquera que cette entrée sera stockée sur le noeud ayant pour clef 24. Maintenant si on ajoute un noeud ayant pour clef 14, l'entrée sera transférée du noeud 24 au noeud 14 lorsque le noeud va joindre le réseau. Supposons à présent que le noeud 14 parte proprement, l'entrée ayant pour clef 12 sera transférée au noeud 24.

Pour mettre en évidence une partie de la tolérance aux pannes, une manière de faire peut être de tuer le mode console en effectuant par exemple un \ovalbox{CTRL-C} et de constater qu'après un laps de temps assez court, le mode graphique s'est mis à jour et les noeuds 2 et 5 ont disparu. De plus, les données associées ont été perdues. Pour gérer ce cas, il faudrait implémenter un système de réplication des données.

% section scénario_d_utilisation (end)

\section{Perspectives d'évolution} % (fold)
\label{sec:perspectives_evolution}

Divers points mériteraient d'être approfondis :

\begin{itemize}
	\item Afin d'améliorer la tolérance aux pannes du point de vue d'un Tracker, il faudrait pouvoir gérer plusieurs trackers qui communiquent entre eux afin qu'ils soient toujours cohérents les uns aux autres : c'est-à-dire que lorsqu'un tracker T ne maintient plus de pair mais que d'autres trackers maintiennent encore des points d'entrée, alors lorsqu'un client contacte le tracker T il faut qu'il soit au courant que d'autres trackers disposent d'un point d'entrée pour pouvoir en donner un au client ou bien le rediriger.
	
	Pour cela, on pourrait s'amuser à utiliser le protocole Chord lui même pour maintenir l'Overlay constituant les trackers. Sachant que les trackers étant en nombre limités, il suffirait alors d'enregistrer dans un fichier connu de tous, les adresses permettant de contacter les trackers;
	\item Avoir une meilleur abstraction pour l'interface cliente afin d'éviter que les pairs créés soient forcemment déployés sur la machine du client. Pour cela, au lieu d'avoir le schéma actuel qui est le suivante : tracker $\leftarrow$ client, il faudrait par exemple introduire une notion de kernel qui utiliserait le tracker comme point d'entrée et qui permettrait de stocker les pairs déployés. Ainsi tout client souhaitant se connecter à un réseau, le fait depuis la référence d'un kernel. Cela permet d'avoir un client léger qui redirige les actions à effectuer sur un ou des kernels et ainsi d'abstraire la notion de déploiement qui peut être réalisée sur un cluster ou bien toujours en local. Cela introduit une indirection supplémentaire qui se traduit par le schéma suivant : tracker $\leftarrow$ kernel $\leftarrow$ client;
	\item Effectuer des benchmarks à grande échelle en utilisant le déploiement ProActive et essayer de comparer à d'autres implémentations existantes telles que \textit{OpenChord}, \textit{JChord}, etc.
	\item Implémenter un système de réplication des données en stockant ces données sur les R successeurs.
	\item Ajouter des tests de non-régression;
	\item Réaliser les scripts BATCH pour windows afin d'avoir un déploiement simplifié pour cet OS.
	\item etc.
\end{itemize}
% section perspectives_evolution (end)
\end{document}